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CONTINUATION SHEET 

Applicant's arguments filed December 8. 2010 regarding rejection of Claims 1-38 under 35 
U.S.C. 103(a) have been fully considered but they are not persuasive. 

Regarding Claims 1 and 20, Applicant states "Examiner has not shown any portion of 
the cited references to disclose or suggest, for example, "...marking packets carrying the Layer-3 
control information." Examiner respectfully disagrees. The McDysan reference, at paragraph 
0009 recites: "Diffserv is an IP QoS architecture that achieves scalability by conveying an 
aggregate traffic classification within a DS field (e.g., the IPv4 Type of Service (TOS) byte or 
IPv6 traffic class byte) of each IP-layer packet header. The first six bits of the DS field encode a 
Diffserv Code Point (DSCP) that requests a specific class of service or Per Hop Behavior (PHB) 
for the packet at each node along its path within a Diffserv domain." Examiner further notes that 
the claimed "control information" is not further defined in the claim language so as to require a 
structure or feature of said information other than being "Layer-3 control information." As the 
DSCP disclosed in McDysan controls the QoS applied to a packet (e.g., in paragraphs 0037 and 
0042) and further is indicative of an IP QoS (i.e., Layer-3), Examiner submits that the claim 
limitation "Layer-3 control information" is met by the disclosure of McDysan. Further, while 
the claim language requires "marking packets carrying the Layer-3 control information," the 
claim language is silent as to how the packets are marked. Therefore, when given its broadest 
reasonable interpretation, Examiner submits that the packet marking via a DSCP code point in IP 
packets in order to distinguish the appropriate treatment for each packet (see paragraphs 0037 
and 0042) disclosed in McDysan meets the broadest reasonable interpretation of the claim 
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limitation "marking packets carrying the Layer-3 control information." Applicant further states 
that "Examiner has not alleged teaching as to "...encapsulating the packets at Layer-2 to uniquely 
identify Layer-2 frames as carrying trusted control information." Examiner respectfully 
disagrees. Examiner notes that the claim language is silent both to how the packets are 
encapsulated such that the trusted control information is uniquely identified and as to what 
constitutes "trusted" traffic; rather, the step of "encapsulating the packets at Layer-2" is claimed 
to result in "uniquely identify(ing) Layer-2 frames as carrying trusted control information." 
Oguchi discloses encapsulating an L2TP VPN packet comprising Layer-2 encapsulation 
(paragraph 0215, Figure 25, wherein a packet containing L2TP is encapsulated with a PPP or 
Ethernet header). Per MPEP 2143.01 : "The test for obviousness is what the combined teachings 
of the references would have suggested to one of ordinary skill in the art, and all teachings in the 
prior art must be considered to the extent that they are in analogous arts." Examiner submits that 
as McDysan and Oguchi are both directed to the formatting and transmission of VPN traffic, the 
references are analogous art. As such, Examiner submits that the combination of the Layer-3 
control packet marking disclosed in McDysan and the L2TP encapsulation disclosed in Oguchi, 
whereby the encapsulation identifies the packet as a tunneled (i.e., trusted) packet, reads on the 
broadest reasonable interpretation of "marking packets carrying the Layer-3 control information" 
and "...encapsulating the packets at Layer-2 to uniquely identify Layer-2 frames as carrying 
trusted control information." Applicant further states "it isn't clear what noun or noun phrase the 
Examiner is using the word "which to refer back to in alleging "which is known in the art as an 
implementation of 'Layer-3' in the OSI-7 layer Interconnect Model (i.e., the network layer)." 
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Examiner notes that the rejection of Claim 1 states that Internet Protocol is an implementation of 
Layer- 3. 

Regarding Claims 2 and 21, Applicant states "DSCP 000 does not disclose or suggest a 
unique protocol identifier." Examiner respectfully disagrees. Examiner notes that the claim 
language solely requires the protocol identifier to be "unique," although the claim language is 
silent as to what aspect of the claimed "protocol identifier" is "unique." As such, Examiner 
submits that the DSCP value disclosed in paragraphs 0037 and 0042 of McDysan uniquely 
identifies how the packet is to be treated (i.e., the values of the DSCP are different than one 
another (i.e., unique)). 

Regarding Claims 4 and 23, Applicant states paragraph 0042 of McDysan "teaches 
away from "determine when marking of control packets is to be done," as they teach remarking 
of all received packets indiscriminately." Examiner respectfully disagrees. McDysan, at Figure 
5 and paragraph 0036, discloses a classifier in the LAN port determining, via by reference to a 
classifier table indexed by multiple indices (e.g., source port and destination port), to determine 
an interface for communication and to send values to a packet marker. Further, at paragraphs 
0037 and 0042, a determination is made with regard to marking of a packet (e.g., marking a 
packet when received from an access network). Examiner notes that there is no requirement in 
the claim language for the claimed "determination" to result in not marking the packet (emphasis 
added by Examiner); rather, the claim language solely requires the determination of "when 
marking of control packets is to be done." As the claim language is non-limiting as to the 
outcome of the determination, Examiner submits that the packet marking disclosed in McDysan 
reads on the broadest reasonable interpretation of the claimed "determination." Applicant further 
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states "Examiner alleges teaching only as to "...marking of a packet...," not "...marking of control 
packets..." Examiner respectfully disagrees. As described with regards to Claim 1, the DSCP 
disclosed in McDysan controls the QoS applied to a packet (e.g., in paragraphs 0037 and 0042), 
and, therefore, reads on the broadest reasonable interpretation of "marking of control packets." 
Applicant further states "the cited portions of the cited references do not disclose or suggest "...to 
determine when marking of control packets is to be done." Examiner respectfully disagrees. As 
stated above, McDysan, at Figure 5 and paragraph 0036, discloses a classifier in the LAN port 
determining, via by reference to a classifier table indexed by multiple indices (e.g., source port 
and destination port), to determine an interface for communication and to send values to a packet 
marker. Further, at paragraphs 0037 and 0042, a determination is made with regard to marking 
of a packet (e.g., marking a packet when received from an access network). 

Regarding Claims 17 and 36, Applicant states "Examiner parenthetically states "(i.e., 
performing control encapsulation)" without any explanation or justification" and the disclosure 
of L2TP tunneling "fails to disclose or suggest "control encapsulation." Examiner respectfully 
disagrees. Examiner notes that the claimed "control encapsulation" is not further defined in the 
claim language so as to require a certain format for the encapsulation. As such, Examiner gives 
the claim language its broadest reasonable interpretation without unnecessarily importing 
limitations from the specification, and submits that any encapsulation that is directed to control 
functions reads on the broadest reasonable interpretation of "control encapsulation." Oguchi 
discloses encapsulating an L2TP VPN packet at Layer 2, wherein the Layer 2 header (i.e., 
performing control encapsulation) comprising Layer 3 encapsulation (paragraph 0215, Figure 25, 
wherein a packet containing an IP header). In order to further describe Figure 25, Examiner 
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turns to paragraphs 0074, which states: ". . .application data is transmitted through an L2TP 
tunnel, an L2TP header and a PPP header are added thereto associated with an encapsulation. 
Moreover, when the edge router transmits the encapsulated packet to the provider network, a 
lower layer media PPP/Ether header.. .are also added." As shown by the above passage, the 
encapsulation of the data disclosed in Oguchi is performed in order to control an aspect of how 
the packet is processed (e.g., establishing a L2TP tunnel and obtaining a session ID as disclosed 
in paragraph 0164 of Oguchi). 

Regarding Claims 3 and 22, Applicant states "Examiner has not shown how an alleged 
motivation of "a need to allow a node in a communication network to collect traffic information 
to thereby achieve load sharing depending on the conditions of the traffic" would have motivated 
one of ordinaiy skill in the art to combine the teachings of Nakamichi, directed to a device and 
method for collecting traffic information, with the teachings of McDysan, directed to a VPN- 
aware CPE edge router, and the teachings of Oguchi, directed to the establishment of virtual 
links between all of the relaying apparatuses belonging to a multicast address group, to allegedly 
yield marking packets carrying Layer- 3 control information using a link-local MPLS label and 
encapsulating the packets at Layer-2 to uniquely identify Layer-2 frames as carrying trusted 
control information." Examiner respectfully disagrees. Examiner recognizes that obviousness 
may be established by combining or modifying the teachings of the prior art to produce the 
claimed invention where there is some teaching, suggestion, or motivation to do so found either 
in the references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 
347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 
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398, 82 USPQ2d 1385 (2007). In the instant case, Nakamichi explicitly states a need in the art to 
avoid congestion in the internet and collect information so that a router is informed of 
information pertaining to a busy condition of a route (paragraphs 0010 and 001 1). Further, 
Nakamichi states that the invention disclosed therein "collect(s) traffic information to thereby 
achieve load sharing depending on the conditions of the traffic" (paragraph 0012). Therefore, 
Examiner notes that the references themselves provide a motivation to combine the disclosed 
teachings. Applicant further states "the cited portions of the cited references do not disclose or 
suggest ". . .wherein the step of marking further comprises: marking the packets using a link-local 
MPLS label." However, Examiner notes that Applicant does not particularly point out how the 
claim language is patentably distinguishable from the cited prior art. 

Regarding Claims 5 and 24, Applicant states "the cited portion of the Yu reference does 
not teach or suggest "applying interface groups to determine when marking of control packets is 
to be done," comprising "applying interface groups to packet communications within a particular 
interface group," as Applicant submits instructing devices to assume mastership of a virtual IP 
address teaches away from "applying interface groups to determine when marking of control 
packets is to be done." Examiner respectfully disagrees. Claims 5 and 24 require "applying 
interface groups to packet communications within a particular interface group." However, 
Examiner notes that the claim language is not further defined so as to further limit the step of 
applying interface groups or the features of a particular interface group. Per MPEP 2106: 
"USPTO personnel are to give claims their broadest reasonable interpretation in light of the 
supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. 
Cir. 1997). Limitations appearing in the specification but not recited in the claim should not be 
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read into the claim. E-Pass Techs., Inc. v. 3Com Corp., 343 F.3d 1364, 1369, 67 USPQ2d 1947, 
1950 (Fed. Cir. 2003) (claims must be interpreted "in view of the specification" without 
importing limitations from the specification into the claims unnecessarily). In re Prater, 415 F.2d 
1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969). See also In re ZLetz, 893 F.2d 319, 321- 
22, 13 USPQ2d 1320,1322 (Fed. Cir. 1989)." Examiner has given said claim language its 
broadest reasonable interpretation in view of the specification to comprise determination of an 
interface for communications. Accordingly, Yu discloses assigning interfaces to communicate 
within and between various types of networks (see Figures 1 and 4 and paragraphs 0022 and 
0025). Further regarding Claims 5 and 24, Yu discloses packet communications between 
interfaces 'a' and 'd' of Network Device A in Figure 1 (at paragraph 0034, wherein tunnel 
interface 'd' is assigned to physical interface 'a' within an interface group). Further, Examiner 
notes that one cannot show nonobviousness by attacking references individually where the 
rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck& Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 
Examiner submits that the combination of the interface group determination disclosed in Yu, the 
marking of a control packet based on interface (paragraph 0036) disclosed in McDysan, and the 
Layer-2 encapsulation disclosed in Oguchi discloses the claim limitation "applying interface 
groups to packet communications within a particular interface group." Further, Applicant states 
that "Examiner has not shown how an alleged motivation of "to withstand failures of network 
device components, without triggering unnecessary failover in a network device" would have 
motivated one of ordinary skill in the art to combine the teachings of Yu, directed to a method 
and apparatus for defining failover events in a network device, with the teachings of McDysan, 
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directed to a VPN-aware CPE edge router, and the teachings of Oguchi, directed to the 
establishment of virtual links between all of the relaying apparatuses belonging to a multicast 
address group, to allegedly yield applying interface groups to packet communications within a 
particular interface group to determine when marking of control packets is to be done, marking 
packets carrying Layer-3 control information, and encapsulating the packets at Layer-2 to 
uniquely identify Layer-2 frames as carrying trusted control information." Examiner recognizes 
that obviousness may be established by combining or modifying the teachings of the prior art to 
produce the claimed invention where there is some teaching, suggestion, or motivation to do so 
found either in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, 
Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In the instant case, Yu explicitly states a need in 
the art to withstand failover events in a network by defining which events should and should not 
trigger a failover in the network device (see paragraphs 0012-0013 of Yu). Therefore, Examiner 
notes that the references themselves provide a motivation to combine the disclosed teachings. 
Further, Applicant states "the cited portions of the cited references do not disclose or suggest 
"wherein the step of applying interface groups further comprises the step of: applying interface 
groups to packet communications within a particular interface group" and "Figure 1 does not 
appear to disclose "interface group defined between interfaces 'a' and 'd' within network device 
A." However, Examiner notes that Applicant solely alleges that the claim language is not 
disclosed or suggested in the prior art and does not particular point how the claims are patentably 
distinguishable from the prior art. 
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Regarding Claims 6 and 25, Applicant states that "Examiner parenthetically 
characterizes "the Internet" as teaching "(i.e., backbone)," without citing any reference or 
providing any justification or explanation as to such characterization." Examiner respectfully 
disagrees. Examiner notes that the claim term "backbone interface group" is not further defined 
in the claim language so as to require any specific characteristics of the interface group. As 
such, Examiner gives the claim language a broadest reasonable interpretation of interfaces 
connected via a backbone network. Yu discloses setting up a tunnel between interface 'd' of 
Network Device A and interface 'e' of Network Device B, which are remotely located from one 
another, via the Internet (paragraph 0033). As such, Examiner submits that the "Internet" 
disclosed in Yu reads on the broadest reasonable interpretation of the claimed "backbone." 
Applicant further states "the block diagram of Figure 4 of the Yu et al. reference does not 
disclose or suggest, as an example, ". ..the step of: applying interface groups to packet 
communications within a backbone interface group." Examiner respectfully disagrees. Figure 4 
of Yu discloses setting up a static tunnel (i.e., "Static Tunnel A") across the Internet (i.e., 
backbone) between two network devices. Given its broadest reasonable interpretation, the 
claimed "backbone interface group" limitation is met by interface 'd', which connects Network 
Device A to the tunnel over the Internet. 

Regarding Claims 7 and 26, Applicant states "Examiner does not appear to allege 
teaching as to "applying interface groups to packet communications within a customer- specific 
interface group." Examiner notes that the claim term "customer-specific interface group" is not 
further defined in the claim language so as to require any specific characteristics of the interface 
group. As such, Examiner gives the claim language a broadest reasonable interpretation of 
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interfaces connecting to a customer. As stated in the Office Action mailed September 8, 2010, 
Yu discloses communications with assigning interface 'a' to interconnect with a Host PC (i.e., 
applying interface groups to packet communications within customer- specific interface group 
given its broadest reasonable interpretation) in Figure 4. Applicant further states the cited 
portions of the cited references do not disclose or suggest "wherein the step of applying interface 
groups to packet communications within a particular interface group further comprises the step 
of: applying interface groups to packet communications within a customer- specific interface 
group." However, Examiner notes that Applicant solely alleges that the claim language is not 
disclosed or suggested in the prior art and does not particular point how the claims are patentably 
distinguishable from the prior art. 

Regarding Claims 8 and 27, Applicant states that "Figure 4 of the Yu reference does not 
disclose or suggest "communications via a static tunnel between Network Device A and Network 
Device D (i.e., peer devices given its broadest reasonable interpretation) via interface 'a' on 
Network Device A," as alleged by Examiner. Examiner respectfully disagrees. Figure 4 clearly 
shows two network devices (Network Device A and Network Device D) connected to one 
another via a static tunnel. Setting up the static tunnel shown in Figure 4 is described further in 
paragraph 0046. Examiner notes that the claim term "peer interface group" is not further 
defined in the claim language so as to require any specific characteristics of the interface group. 
As such, Examiner gives the claim language a broadest reasonable interpretation of interfaces 
connecting to peer devices. Given its broadest reasonable interpretation, the claimed "peer 
interface group" limitation is met by the disclosed interface assignment (i.e., interface 'd') used 
in order to communicate between like devices (i.e., Network Device A and Network Device D). 
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Applicant further states the cited portions of the cited references do not disclose or suggest 
"wherein the step of applying interface groups to packet communications within a particular 
interface group further comprises the step of: applying interface groups to packet 
communications within a peer interface group." However, Examiner notes that Applicant solely 
alleges that the claim language is not disclosed or suggested in the prior art and does not 
particular point how the claims are patentably distinguishable from the prior art. 

Regarding Claims 9 and 28, Applicant states "the Yu reference appears to teach away 
from the Examiner's assertion that "Examiner has given the claim language "applying interface 
groups" its broadest reasonable interpretation in view of the specification to comprise 
determination of an interface for communications" and "one of ordinary skill in the art at the 
time the invention was made, in view of the Yu, reference, would not have understood "...define 
an interface group..." to merely mean "determination of an interface for communications, as 
alleged by Examiner." Examiner notes that Applicant specification broadly describes interface 
groups at paragraph 0026: "The second is to apply a new concept of interface groups, whereby a 
router can determine whether a packet should be marked or not." However, the step of applying 
interface groups is not discussed in Applicant's specification and not further defined in the claim 
language. Therefore, absent any definition of the term in the specification, Examiner submits 
that a broadest reasonable interpretation of the claim term "applying interface groups" to 
reasonably encompass any interpretation of the plain meaning of "applying interface groups," 
such as determining the interfaces assigned to particular interface types disclosed in Yu. Further, 
Examiner notes that Applicant solely alleges that the claim language (i.e., the step of applying 
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interface groups) is not disclosed or suggested in the prior art and does not particular point how 
the claims are patentably distinguishable from the prior art. 

Regarding Claims 10 and 29, Applicant states that "Figure 4 of the Yu reference does 
not disclose "applying interface groups to packet communications between backbone and 
customer- specific groups (Figure 4, connections between backbone (e.g., in Network Device A 
between interfaces 'a' and 'd' and customer networks (e.g., between Network Device A at 
interface 'a' and Host PC 12)." Applicant further states that "Yu teaches away from "applying 
interface groups" to connections between backbone. . . .and customer networks. . .as Applicant 
submits such an alleged "applying interface groups" would appear to render inoperable the 
"tunnel failover. . .without running a dynamic routing protocol" described in paragraph [0034] of 
the Yu reference." However, Examiner notes that Applicant has provided no evidence that the 
disclosure of defining interfaces between a backbone network and a customer network, such as 
that disclosed in Yu, would render a failover inoperable. Further, Examiner notes that Applicant 
has not described how an interpretation of the claim term "applying interface groups," which is 
not defined in the specification as described above, would lead to such a conclusion. Further, 
Applicant states that "the cited portions of the cited references do not disclose wherein the step 
of applying interface groups to packet communications between interface groups further 
comprises the step of: applying interface groups to packet communications backbone and 
customer- specific interface groups." However, Examiner notes that Applicant solely alleges that 
the claim language (i.e., the step of applying interface groups) is not disclosed or suggested in 
the prior art and does not particular point how the claims are patentably distinguishable from the 
prior art. 
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Regarding Claims 11 and 30, Applicant states that "Figure 4 of the Yu reference does 
not disclose "applying interface groups to packet communications between customer- specific 
and peer interface groups (Figure 4, connections between peer (e.g., between Network Device A 
and Network Device D) and customer networks (e.g., between Network Device A at interface 'a' 
and Host PC 12)." Applicant further states that "Yu teaches away from "applying interface 
groups" to connections between peer. . . .and customer networks. . .as Applicant submits such an 
alleged "applying interface groups" would appear to render inoperable the "tunnel 
failover. . .without running a dynamic routing protocol" described in paragraph [0034] of the Yu 
reference." However, Examiner notes that Applicant has provided no evidence that the 
disclosure of defining interfaces between a backbone network and a customer network, such as 
that disclosed in Yu, would render a failover inoperable. Further, Examiner notes that Applicant 
has not described how an interpretation of the claim term "applying interface groups," which is 
not defined in the specification as described above, would lead to such a conclusion. Further, 
Applicant states that "the cited portions of the cited references do not disclose wherein the step 
of applying interface groups to packet communications between interface groups further 
comprises the step of: applying interface groups to packet communications customer- specific 
and peer interface groups." However, Examiner notes that Applicant solely alleges that the 
claim language (i.e., the step of applying interface groups) is not disclosed or suggested in the 
prior art and does not particular point how the claims are patentably distinguishable from the 
prior art. 

Regarding Claims 12 and 31, Applicant states that "Examiner parenthetically 
characterizes "the Internet" as teaching "(i.e., backbone)," without citing any reference or 
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providing any justification or explanation as to such characterization." Examiner respectfully 
disagrees. Examiner notes that the claim term "backbone interface group" is not further defined 
in the claim language so as to require any specific characteristics of the interface group. As 
such, Examiner gives the claim language a broadest reasonable interpretation of interfaces 
connected via a backbone network. Yu discloses setting up a tunnel between interface 'd' of 
Network Device A and interface 'e' of Network Device B, which are remotely located from one 
another, via the Internet (paragraph 0033). As such, Examiner submits that the "Internet" 
disclosed in Yu reads on the broadest reasonable interpretation of the claimed "backbone" and 
that the interface 'd' in Network Device A belongs to a "backbone interface group." Applicant 
further states that citing Network Device A between interfaces 'a' and 'd' as "teaching a 
"backbone" is "inconsistent and contradictory." Examiner respectfully disagrees. Figure 4 of 
Yu shows that Interface 'd' of Network Device A is connected to the Internet, which Examiner 
has established as teaching "backbone." Therefore, the disclosure of applying interface groups to 
packet communications between peer interface groups (e.g., between Network Device A and 
Network Device D) and backbone (e.g., in Network Device A between interfaces 'a' (to a LAN) 
and 'd' (to the Internet)) reads on the broadest interpretation of the claimed "applying interface 
groups between backbone and peer interface groups." Further, Applicant states that "the cited 
portions of the cited references do not disclose wherein the step of applying interface groups to 
packet communications between interface groups further comprises the step of: applying 
interface groups to packet communications backbone and peer interface groups." However, 
Examiner notes that Applicant solely alleges that the claim language (i.e., the step of applying 
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interface groups) is not disclosed or suggested in the prior art and does not particular point how 
the claims are patentably distinguishable from the prior art. 

Regarding Claims 13 and 32, Applicant states "Examiner appears to characterize the 
teachings of Holden in a manner that teaches away from the subject matter of claims 13 and 32." 
Applicant further states "claims 13 and 32 depend indirectly from claims 1 and 20, which recite 
"marking packets carrying the Layer-3 control information," while the Examiner alleges teaching 
as to marking "an ICMP Echo Reply." Examiner respectfully disagrees. Examiner notes that the 
claim language in claims 13 and 32 requires "applying interface groups to communication of 
ICMP packets." While McDysan is relied on disclose applying interface groups to determine 
when marking of control packets is to be done (Figure 5 and paragraph 0036, wherein the 
classifier in the LAN port determines by reference to a classifier table indexed by multiple 
indices, such as source port and destination port, to determine an interface for communication 
and to send values to a packet marker), as claimed in parent claims 4 and 23, Holden discloses a 
secure network interface unit (SNIU) that marks the protocol and type fields to indicate an ICMP 
Echo Reply, signs the packet, and sends through an interface (column 20, line 66 - column 21, 
line 10). Per MPEP 2143.01 : "The test for obviousness is what the combined teachings of the 
references would have suggested to one of ordinaiy skill in the art, and all teachings in the prior 
art must be considered to the extent that they are in analogous arts." As such, Examiner submits 
that the combination of the packet marking based on source and destination port identifiers 
disclosed in McDysan, the encapsulation disclosed in Oguchi, and the ICMP Echo packet 
processing disclosed in Holden discloses the claim limitation "applying interface groups to 
communication of ICMP packets." 
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Regarding Claims 14 and 33, Applicant states "assigning predetermined port numbers 
to LSP ping messages" fails to disclose or suggest applying interface groups to determine when 
marking of control packets is to be done, wherein applying interface groups to determine when 
marking of control packets is to be done comprises applying interface groups to communication 
of ping packets, and marking packets carrying Layer-3 control information, as "assigning 
predetermined port numbers to LSP ping messages" does not teach or suggest "to determine 
when marking of control packets is to be done." Examiner notes that McDysan is relied on 
disclose applying interface groups to determine when marking of control packets is to be done 
(Figure 5 and paragraph 0036, wherein the classifier in the LAN port determines by reference to 
a classifier table indexed by multiple indices, such as source port and destination port, to 
determine an interface for communication and to send values to a packet marker), as claimed in 
parent claims 4 and 23. However, Examiner notes that Applicant solely alleges that the claim 
language (i.e., "applying interface groups to ping packets") is not disclosed or suggested in the 
prior art and does not particular point how the claims are patentably distinguishable from the 
prior art. 

Regarding Claims 15 and 34, Applicant states "assignment of traceroute packets to a 
virtual router address indicative of a loopback interface" fails to disclose or suggest applying 
interface groups to determine when marking of control packets is to be done, wherein applying 
interface groups to determine when marking of control packets is to be done comprises applying 
interface groups to communication of traceroute packets, and marking packets carrying Layer-3 
control information, as "assignment of traceroute packets to a virtual router address indicative of 
a loopback interface" does not teach or suggest "to determine when marking of control packets is 
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to be done." Examiner notes that McDysan is relied on disclose applying interface groups to 
determine when marking of control packets is to be done (Figure 5 and paragraph 0036, wherein 
the classifier in the LAN port determines by reference to a classifier table indexed by multiple 
indices, such as source port and destination port, to determine an interface for communication 
and to send values to a packet marker), as claimed in parent claims 4 and 23. However, 
Examiner notes that Applicant solely alleges that the claim language (i.e., "applying interface 
groups to traceroute packets") is not disclosed or suggested in the prior art and does not 
particular point how the claims are patentably distinguishable from the prior art. 

Regarding Claims 16 and 35, Applicant states "setting up a tunnel interface with a NOC 
(paragraph 0136) and communicating packets, including control information, with the NOC via 
the tunnel (paragraphs 0141- 0143)" fails to disclose or suggest applying interface groups to 
determine when marking of control packets is to be done, wherein applying interface groups to 
determine when marking of control packets is to be done comprises applying interface groups to 
communication of packets from Network Operations Center (NOC) hosts, and marking packets 
carrying Layer-3 control information, as "setting up a tunnel interface with a NOC (paragraph 
0136) and communicating packets, including control information, with the NOC via the tunnel 
(paragraphs 0141-0143)" does not teach or suggest "to determine when marking of control 
packets is to be done." Applicant further states "setting up a tunnel interface with a NOC" does 
not disclose or suggest "applying interface groups to communication of packets from Network 
Operations Center (NOC) hosts." However, Examiner notes that Applicant solely alleges that 
the claim language (i.e., "applying interface groups to communication of packets from NOC 
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hosts") is not disclosed or suggested in the prior art and does not particular point how the claims 
are patentably distinguishable from the prior art. 

Regarding Claims 18 and 37, Applicant states "the Examiner does not appear to allege 
any teaching or suggestion as to, for example, "unmarked control packets." Rather, Applicant 
notes, with respect to claims 1 and 20, from which claims 18 and 37 depend, the Examiner 
alleges "...McDysan discloses marking packets via a DSCP code point in IP packet .... " Thus, 
Applicant submits the combination of references cited by the Examiner appear to teach away 
from "unmarked control packets." Moreover, Applicant submits the "cells" of Johansson fail to 
disclose or suggest "unmarked control packets." Applicant states that the cited portions of the 
cited references do not disclose "control packets." Examiner respectfully disagrees. The claim 
language "control packets" is not further defined in the claim language so as to further limit the 
content or structure of the claimed "control packet." As such, Examiner has given the claim term 
its broadest reasonable interpretation without unnecessarily importing limitations from the 
specification and interpreted "control packet" to comprise any messaging related to control of 
communications (e.g., setup, teardown, parameter management, etc.). Further, per MPEP 
2143.01 : "The test for obviousness is what the combined teachings of the references would have 
suggested to one of ordinary skill in the art, and all teachings in the prior art must be considered 
to the extent that they are in analogous arts." The McDysan, Oguchi, and Johansson references 
are directed to processing data packets and are therefore in analogous arts." While McDysan 
discloses processing control information in a network (paragraphs 0037 and 0042), the 
combination of McDysan and Oguchi does not disclose processing the control packets at a line 
rate. In the same field of endeavor, Figure 4a, step 410 of Johansson "determines when a 
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predetermined number Input RateLimit of Cells are received" (column 10, lines 45-47), wherein 
the cells contain basic ATM functions such as VPJ/VCI translation and payload type indicator 
operations (i.e., the cells are unmarked). As such, Johansson provides a general teaching of a 
rate-limited queue receiving unmarked control packets. 

Regarding Claims 19 and 38, Applicant states "the cited portions of the cited references 
do not disclose or suggest "receiving the packets as received packets; and processing the 
received packets at a line rate." While the Examiner cites "(paragraph 0050)" of the Hussey 
reference, Applicant submits "(paragraph 0050)" of the Hussey reference states, in part, 
"...receives a packet data stream via the communication network 1 10 at a line rate .... " Applicant 
submits such teaching does not disclose or suggest "receiving the packets as received packets" 
and "processing the received packets at a line rate."" However, Examiner notes that Applicant 
solely alleges that the claim language (i.e., "receiving the packets as received packets" and 
"processing the received packets at a line rate") is not disclosed or suggested in the prior art and 
does not particular point how the claims are patentably distinguishable from the prior art. 
Applicant states "even if an attempt were made to combine the teachings of the Hussey reference 
and the McDysan reference, such an attempted combination would not yield the subject matter of 
Claims 19 and 38." Per MPEP 2143.01 : "The test for obviousness is what the combined 
teachings of the references would have suggested to one of ordinary skill in the art, and all 
teachings in the prior art must be considered to the extent that they are in analogous arts." The 
McDysan, Oguchi, and Hussey references are directed to processing data packets and are 
therefore in analogous arts. Further, Hussey discloses a processor pool aggregation technique 
wherein a communication device "receives a packet data stream via the communication 
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network. . .at a line rate that might otherwise overwhelm the processing capabilities of the 
NIC. . .and result in dropped packets and reduced quality of service" (paragraph 0050). 

For the reasons stated above, rejection of Claims 1-38 under 35 U.S.C. 103(a) is 
maintained. 



